AlwaysOn の WorkSpaces の Windows Update をコントロールしたい

まさを

2019.10.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさま Xin chao !

Amazon WorkSpaces は、フルマネージドの仮想デスクトップサービスで、ハードウェアの調達や仮想デスクトップ基盤の構築を行うことなく Windows デスクトップ環境を用意することができます (OS で Linux も選択できます)。

WorkSpaces からインターネット閲覧を許可するような使い方の場合、ウイルス対策ソフトを使用するのはもちろんのこと、多層防御の観点からも Windows Update によるセキュリティパッチの適用を、適切に行っていくことが推奨されます。

今回は、WorkSpaces に対するパッチ適用について、試してみました。

WorkSpaces にパッチを適用する仕組み

各 WorkSpace に対するパッチ適用は、Windows Update により保守管理時間枠 (メンテナンスウィンドウ) 内で行われます。 AutoStop (時間課金) モードの WorkSpaces の場合、保守管理時間枠を既定値 (毎月第 3 月曜日から始まる毎日 0:00～5:00) から変更することはできません。

Q: Amazon WorkSpaces サービスに保守管理時間枠はありますか?

(中略)

AutoStop (時間課金) モードの WorkSpaces の場合、デフォルトの保守管理時間枠は通常、WorkSpaces の AWS リージョンのタイムゾーンで毎月第 3 月曜日から始まる、毎日 0:00～5:00 です。保守管理時間枠は、最大 2 週間かかることがあります。WorkSpaces は、保守管理時間枠内のいずれかの日にメンテナンスされます。AutoStop WorkSpaces のメンテナンスモードは、WorkSpaces マネジメントコンソールで設定できます。詳細は、WorkSpace の実行モードの管理をご覧ください。現時点では、AutoStop モードの WorkSpaces の保守管理時間枠を変更することはできません。

Amazon WorkSpaces のよくある質問 - メンテナンスとセットアップより抜粋

一方、AlwaysOn (月額課金) モードの WorkSpaces の場合、グループポリシー等により OS の設定にて変更することが可能です。

Q: Amazon WorkSpaces サービスに保守管理時間枠はありますか?

(中略)

AlwaysOn (月額課金) モードの WorkSpaces の場合、メンテナンスのスケジュールは WorkSpace の OS 設定により管理されます。デフォルトの保守管理時間枠は、毎週日曜日午前 0:00～4:00 の 4 時間です (この時間枠は Amazon WorkSpaces に対して設定したタイムゾーン設定を基にしています)。この時間帯は WorkSpaces をご利用いただけません。

(後略)

Q: Amazon WorkSpaces のソフトウェア更新パッチはどのように適用されますか?

デフォルトでは、Amazon WorkSpaces はソフトウェア更新をインストールするよう設定されています。Amazon Linux WorkSpaces では最新のセキュリティおよびソフトウェアの更新パッチがインストールされ、Windows の Amazon WorkSpaces では Windows Updates がオンになります。この設定はカスタマイズ可能です。代替のパッチ管理アプローチを使うこともできます。更新は毎週日曜日午前 2 時にインストールされます。

いずれも Amazon WorkSpaces のよくある質問 - メンテナンスとセットアップより抜粋

今回は、グループポリシーを使って、AlwaysOn (月額課金) モードの WorkSpaces に対する Windows Update をコントロールしてみます。

試してみた

想定する WorkSpaces 利用環境

以下のような WorkSpaces の利用環境を想定します。

AlwaysOn のその名のごとく、各 WorkSpace が常時起動していることを前提に、WorkSpace 上で夜間に時間を要する集計処理を実行させておき、翌朝確認するような使い方を行っている
ディスクアクセスが集中するパッチ適用が、集計処理中に実行されることを避けたい
集計処理が中断されないよう、OS が自動的に再起動されることを防ぎたい
WorkSpaces を利用しているのはごく限られた利用者のみで、いずれの利用者も Windows Update の重要性を充分理解しており、各自の利用状況に応じて Windows Update を手動で実行できる程度のリテラシーを要している

Windows Update 要件

想定する利用環境をもとに、Windows Update に対する要件は以下の通りとします。

各 WorkSpace で必要なパッチのダウンロードは、自動的に行う (パッチの適用は自動では行わない)
必要なパッチのダウンロードが完了したら、画面に通知を表示する
各 WorkSpace 利用者は手動で Windows Update によるパッチ適用を実行する

環境

Simple AD を使って WorkSpaces を既に利用している

Microsoft AD や AD Connector を介してオンプレミス環境の Active Directory を使っている場合でも、基本的な流れは同じですが、今回は Simple AD 環境で試しました。

Simple AD の管理者情報を有している

[Active Directory ユーザーとコンピューター] および [グループポリシーの管理] をインストール済みの WorkSpace がある

インストールした環境がない場合、以下を参考に、特定の WorkSpace または WorkSpaces と同じ Active Directory ドメインに参加した EC2 にインストールします。

Windowsにリモートサーバー管理ツールをインストールする方法

グループポリシーの設定

Windows Update 要件を満たすような、必要最低限のポリシーを設定してみます。

[Active Directory ユーザーとコンピューター] での操作

[Active Directory ユーザーとコンピューター] を "別のユーザーとして実行" から、Simple AD の管理者で起動し、組織単位 (OU) を新規作成します。今回は、"OU-WindowsUpdate" という名前で作成しています。後述の手順で、この組織単位 (OU) に、Windows Update のコントロール対象となるコンピュータのアカウントを配置し、グループポリシーを適用します。

"別のユーザーとして実行" する方法については、以下をご参照ください。

WorkSpaces で不要なユーザーを削除する

[グループポリシーの管理] での操作

[グループポリシーの管理] を "別のユーザーとして実行" から、Simple AD の管理者で起動し、グループポリシーオブジェクトを新規作成します。今回は、"GPO-WindowsUpdate" という名前で作成しています。

作成したグループポリシーオブジェクトを編集します。この時点では、いずれのポリシーも "未構成" の状態になっています。

"自動更新を構成する" ポリシーを編集します。この設定により、各 WorkSpace に必要なパッチが自動的にダウンロードされるようになります。

状態 : 有効
自動更新の構成 : 3 - 自動ダウンロードしインストール通知

"非管理者による更新の通知の受信を許可する" ポリシーを編集します。この設定により、パッチのダウンロード完了後、WorkSpace の管理者権限がないユーザーに対しても通知が行われるようになります。

状態 : 有効

グループポリシーオブジェクトは、設定した 2 つのポリシーが "有効" の状態になりました。

組織単位 (OU) に、作成したグループポリシーオブジェクトをリンクします。組織単位 (OU) を右クリック → [既存 GPO のリンク (L)...] をクリックします。

グループポリシーオブジェクトの一覧から、作成したグループポリシーオブジェクト ("GPO-WindowsUpdate") を選択します。

作成したグループポリシーオブジェクトが、組織単位 (OU) にリンクされました。

[Active Directory ユーザーとコンピューター] での操作

作成したグループポリシーを適用するコンピュータ (＝WorkSpace) のコンピュータアカウントを、作成した組織単位 (OU) に移動します。コンピュータアカウントを右クリック → [移動 (V)...] をクリックします。

オブジェクトの移動先のコンテナーとして、作成した組織単位 (OU) ("OU-WindowsUpdate") を選択します。

組織単位 (OU) ("OU-WindowsUpdate") を確認すると、コンピュータアカウントが移動されています。

グループポリシーの動作確認

WorkSpace 上での操作 (オプション)

以下の操作は必須ではありませんが、グループポリシーは、既定で 90 分間隔 (＋最大 30 分のオフセット時間) で適用されるため、動作を確認することができる状態になるまでに時間を要します。すぐに動作を確認したい場合は、手動でグループポリシーを適用することが可能です。

また、グループポリシーが適用された後も、Windows Update への更新プログラムの確認は、既定で 22 時間 (-最大 20%) 間隔で行われるため、Windows Update に関する想定した動きを開始するまでに丸 1 日を要する場合があります。手動ですぐに更新プログラムを確認することが可能です。

いずれもグループポリシーの設定で、間隔を短縮することが可能ですが、実運用環境で無計画に間隔を短縮した場合、インターネットやサーバーへのトラフィックが増えるなどの弊害も考えられるため、ご注意ください。

設定で間隔を短縮せずに、即時グループポリシーを適用するには、PowerShell (またはコマンドプロンプト) で以下のコマンドを実行します。

gpupdate /force

さらに適用したグループポリシーの設定に基づき、即時 Windows Update へ更新プログラムを確認するには、PowerShell で以下のコマンドを実行します。

$AutoUpdates = New-Object -ComObject "Microsoft.Update.AutoUpdate"
$AutoUpdates.DetectNow()

Windows エクスプローラーで C:\Windows\SoftwareDistribution\Download フォルダの内容を確認すると、パッチのダウンロードが開始されたことが推察できます。

パッチのダウンロードが完了し、インストールできる状態になると、デスクトップにメッセージが表示されます。

メッセージをクリック、または、[設定] - [更新とセキュリティ] を開くと、インストールの準備が整っているパッチを確認できます。

[今すぐインストール] をクリックすると、パッチの適用が開始されます。

パッチの適用が完了すると、再起動が要求されていることが分かります (適用するパッチによっては再起動が要求されない場合もあります)。

OS の再起動を行うと、パッチの適用が完了します。

まとめ

AlwaysOn (月額課金) モードの WorkSpaces で、Windows Update によるパッチ適用のタイミングを変更する方法について試してみました。オンプレミスの Windows 環境で WSUS (＝Windows Server Update Services) をお使いになっていた方には、WorkSpaces だから特別という部分はないと感じられると思いますが、WSUS を使ったことがない方が「この設定はカスタマイズ可能です」と言われても、少しハードルが高く感じられるのではないかと思います。

今回試した設定以外に、決められた時間にパッチのインストールを強制したり、AWS 内やオンプレミス環境内に構築済みの WSUS サーバーからパッチをダウンロードさせる等の設定も可能です。

組織単位 (OU) ごとに設定可能なので、特定の WorkSpace に対してのみ試すということもできますので、いろいろ試してみてはいかがでしょうか。